nodejs: fix accept_waveform error handling and add missing recognizer/model methods - #2056

Two related changes to the Node.js binding.

Fix: accept_waveform errors were reported as end-of-utterance

vosk_recognizer_accept_waveform is declared to ffi as returning 'bool':

'vosk_recognizer_accept_waveform': ['bool', [vosk_recognizer_ptr, 'pointer', 'int']],

but the C API returns an int and documents three states:

 *  @returns 1 if silence is occured and you can retrieve a new utterance with result method
 *           0 if decoding continues
 *           -1 if exception occured

ffi coerces the non-zero -1 to true, so when Recognizer::AcceptWaveform throws and
vosk_api.cc returns -1, the Node caller sees exactly what it sees on a successful
endpoint. Every demo follows the if (rec.acceptWaveform(data)) ... rec.result() shape,
so the failure surfaces as a stale/empty result rather than an error.

This declares the return as 'int' and throws on a negative value, matching what the
Python binding already does:

res = _c.vosk_recognizer_accept_waveform(self._handle, data, len(data))
if res < 0:
    raise Exception("Failed to process waveform")

acceptWaveform and acceptWaveformAsync still resolve to a boolean, so existing
callers and all of the demo/ scripts are unaffected on the success path.

Add the configuration calls that were already exported

These are in vosk_api.h and reachable from the C, Python, Java and C# bindings, but
were not bound here — the README notes that "some methods are not yet fully implemented".

Also exports an EndpointerMode enum mirroring VoskEndpointerMode, named as in the
Python binding:

const { Recognizer, EndpointerMode } = require('vosk');
rec.setEndpointerMode(EndpointerMode.SHORT);

setGrammar takes an array and stringifies it, consistent with how the grammar
constructor option is already handled; [] switches back to the default model graph.

All new symbols already ship in the 0.3.75 libraries that this package version pairs
with, so ffi.Library resolution is unaffected.

Notably left out: the batch/GPU calls (need a CUDA build to exercise) and the text
processor calls (vosk_text_processor_itn returns a strduped buffer with no
corresponding free in the C API, so binding it would leak).

JSDoc is kept in the existing style and the file still passes tsc --checkJs with no
new diagnostics.